November 08, 2008
So I've been cleaning up my blog's code base and decided to switch to unobtrusive javascript. I've heard many reasons advocating its use but for some reason, they never stuck. Until a couple of weeks ago when I worked on a Railsrumble project with a couple of buddies of mine, one of which was a big advocate of unobtrusive javascript using LowPro. Actually using unobtrusive javascript turned out to be much more gratifying that I anticipated. It satisfied some inner OCD tendencies of mine that a lot of programmers share and it made developing javascript'd UIs much easier to develop and much much easier to maintain.
Looking back, I don't think know why I chose to use the Rails javascript helpers or RJS; I like writing javascript, especially when there are great frameworks out there like LowPro and Prototype. The fact that the Rails javascript helpers generate inline javascript, which sometimes turns out being longer than a simple one-liner, is kind of gross. As for RJS, the fact that it's generates code that contains both the data and the logic makes OCD baby Jesus cry.
The separation of HTML (markup), CSS (presentation), Javascript (interactivity) is almost as awesome as the separation of church and state...oh wait, crap.
If you haven't already switched, do it now!
November 06, 2008
Just as a little background, I'm working on adding the concept of rounds to an application. A "round" is simply an organization unit with a start and end date. Each round has_many :events, and each event has an end date, defined as its moment of expiration. The validation logic for these two models is that an event's end date must be between the round's start/end dates and that rounds cannot overlap. This isn't an issue at all with things like fixtures since that's all manually specified. But I'm using FactoryGirl for generating my test data so things get a little tricky.
Read more...
November 02, 2008
I've decided to move my blog to asemanfar.com, Asemanfar being my last name. The old domain will still work, but update your RSS readers to point to http://feeds.feedburner.com/Asemanfar.
That is all.
October 24, 2008
I spent a couple hours today removing any blog-specific details from my blog engine so that I can generic-ify it and make it open source. There were two issues that I ran into with git after making all the generic-ifying changes.
Clearing Commit History
The first was getting rid of all the commit history. I have some sensitive data (such as API keys/secrets) that I'd prefer not to make publicly available. There are two routes that I found to achieving this. The first is to create a shallow clone:
1 git clone --depth 1 original_repo.git new_bare_repo.git
Unfortunately that didn't work as expected, it created a complete clone. I thought maybe it was because it was creating hard-links since it's a clone of a local git repository. So I added --no-hardlinks to the clone with no avail. Lastly, I tried tricking git into thinking it was a remote repository by simply ssh'ing into my local machine:
1 git clone --depth 1 ssh://localhost/path/to/original_repo.git new_bare_repo.git
Strangely, that yielded a new repository with a three commit history; I have no idea how it picked three. But since only my last commit removed sensitive data, three wasn't going to cut it. I reverted to a more primitive solution:
1 cp -r original_repo.git new_bare_repo.git
2 cd new_bare_repo.git
3 rm -rf .git
4 git init
5 git add .
6 git commit -m "generic blog"
Although that works, I feel like it's a less elegant solution especially because it wouldn't work if I wanted more than a one-commit history. Anyone have ideas to why the depth flag doesn't work as expected?
Re-applying app-specific changes
So now that I have a new generic blog factored out of my customized blog, I want my customizations to be applied on-top of the generic version so that I could maintain a "blog-name" branch with all my changes on top of the generic version. Here's how I did that:
1 cd original_repo.git
2
3 git diff --binary HEAD HEAD^ > ../app-specific.diff
4 cd ../new_bare_repo.git
5 git checkout -b blog-name
6 git apply ../app-specific.diff
7 git commit -m "import blog-specific changes"
Now I have a new repository with no commit history (unfortunately) with a generic blog as the master branch and a branch for my blog-specific changes.
I'll be pushing this to GitHub sometime in the future. I still want to do some significant clean up so that it's more customization-friendly for anyone who wants to use it.
